Part 48: Assignment #22: Cryptocurrency Deposit Terminal
Cryptocurrency Deposit Terminal
Before I say anything else, let me be clear about this: this is not a Sun Haotian project, despite coming from Lili. So: no need to break out the aluminum foil just yet.
That said... this terminal accepts cash deposits? This can't be intended for China. The only people using cash in Shenzhen are the re-enactors in the Three Kingdoms Land down the road.*
I'm sure the spec'll explain more, but but color me confused.
*I do mean only. I saw a man begging, with a QR code for mobile payment apps.
...color me confused-er. Why would the spec say ¥ bills? I'm going to have to assume they mean generic currency bills... either that, or this is targeted at cash-hoarders in China who are also OK with investing in cryptocurrencies.
Which arguably would at least potentially make sense as a target market, but how many such hoarders can there be? I still think this is more meant for international use.
Anyway, design-wise, this needs to store a value, reconstitute it later, and also count how much cash was deposited. Thankfully, the card reader is non-blocking. From the looks of it, there'll need to be an expander on the three 'cash' inputs, and a RAM chip to record the user's account number. After that, it's... as many MCs as I need, I guess.
[ ~ ]
Let me be clear to start off: I know this design is super clunky. This is a prototype only. (¥16, 860 average power, in case anyone is wondering.)
The small MC sits on the card reader, and stores the user's account number. If the card is ejected, it notifies the MC on the right, and resets the address pointer of the memory chip so it can store the next account number.
The big MC on the left is on expander duty. Every time unit, it adds any cash the user put in to its acc. It treats 20 as 2, 50 as 5, and 100 as 10 - this is so that it can push the value out on its p1, where the MC on the right can read it.
This MC will reset its counter if its p0 is on, which the MC on the right sets for two time units at the end of the gathering-everything-together phase.
The MC on the right is the one that pulls everything together. When the small MC notifies it, it checks the RAM chip, spits out the account number, and then gets the value from the lower-left MC, and outputs the amount of cash deposited.
Easy, straightforward... inefficient. I could probably remove at least one of the MCs - there doesn't need to be two chips for writing and reading to the RAM. It could well take a refactoring of the entire design.
Fortunately, there appears to be some 'design space' on the two upper MCs....
[ ~ ~ ]
Design space found! It turns out the key was making the chip that handled cash-manager duty also listen to radio pings. That MC (on the left) does double duty now; if the value received from the radio is a positive number (i.e. part of an account number), it forwards that to the second MC. It also forwards 'eject card' (-1) events.
Once it's done that, it'll check the expander, and adjust its acc accordingly if the user put in cash.
The MC on the right does two different things, depending on what it receives. Any positive (account) numbers go in the attached memory chip. If it receives a -1, though, it reads the first eight cells of the memory, outputting them over the network. It then pings the first MC, which outputs the value of its acc (how much cash was put in) to the network. Then the first MC resets its acc to 0 so the next user can step up.
This solution is more serviceable than the original - ¥13, and 718 average power per run.
I'm still not satisfied with it.
I know. I think I'm a bit of a perfectionist. But it just feels like it's possible (theoretically) to trim it down to less than ¥13, which probably means downgrading the second MC to a MC4000. I have to take its script down two lines, from 11 lines to 9.
It can't be too hard, right? I'll at least try it, and see how far I can get.
[ ~ ~ ~ ]
This took me hours to figure out, but it's worth it! ¥11, and 834 average power per run.
How it works is a bit different from the last two prototypes. The key was that the MC on the right (now the small one), only has to slx and wait for input at two points:
1. Before the user inserts their card.
2. Before the user ejects their card.
When the first MC is passing the card numbers to the second MC, the second MC doesn't have to wait because it all happens in the same time unit. And because a card insert is followed by a card eject, the second MC can just switch between "read card number" and "write card number" mode without the first MC telling it what to do.
What this means is that the second chip doesn't have to have a loop with a jmp in it - it can just disable the slx and have its entire script be the loop, until it's done reading or writing.
So here's what each chip does now:
The first MC, on the left, checks if there's no input (-999), an account number part (0-9), or eject (-1).
It sends any account number parts to the second MC.
If there's an eject signal, it sends the amount of money the user has deposited to the second MC instead!
(The first MC also checks the expander for money being inserted and updates its acc after it's notified the second MC properly.)
The second MC, on the right, waits for the first part of an account number or an eject signal. Its acc tells it whether it's in input mode (100) or output mode (0), and gets toggled by the not once it's done waiting. Depending on which mode it's in, it either reads from the memory chip, or writes to the output.
The important bit is after that, once the script loops around to the top. The teq x3 0 checks if all eight values have been read or written. If not, the slx, the not, and the mov 6 x3 (which resets the address pointer on the memory chip) don't happen, so the script just keeps looping without waiting for any time units.
Effectively, the entire chip is the loop.
Once the MC has read or written all eight values, it goes back to waiting. If it wrote the values to the network, it also finishes off by writing the value it received from the first MC (which will be the amount of money) to the network as well. (The + teq x3 0 / mov x0 x1 at the bottom are what do this.)
If you're curious why the second MC writes the money value now instead of the first: if you use slx to wake up a MC, you have to have that MC read the value that woke it up or you get an error. So I had to do something with the ping when it woke the second MC up to write the card number out.
Anyway! It's done, it works, I don't want to think about it, I have a bit of a headache... time to send it to Lili.
Come on, Carl. You only absolutely control a currency if it's a centralized* cryptocurrency, with a single signer (you) for each transaction.
Besides, I doubt any of the people who would use this terminal would listen to you...
I wonder if there's a bar we could go to with cryptocurrency-themed cocktails? If not, someone should open one.
*It's debatable if it's a permissioned currency, and you know everyone signing off and can horse them into doing what you ask. Would that make it quasi-centralized?
P.S.: Secret project update time! It's coming along great, and looks like THIS now...
Only three more sections to go!